• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr8298-81e9c33 on your iPhone

Thanks for the review @ealeksandrov! I took a look at your suggestions; let me know what you think.

In the trunk we have additional refresh action which error may be unhandled.

Thanks for the heads up! I merged trunk to take a look at the refresh action and handled the error with the changes outlined below.

Do you think we can connect dismiss + notice actions directly, so it's more obvious without relying on UIKit lifecycle (viewWillDisappear)? For example: dismiss(with notice: Notice?) on HostingVC can trigger both actions with clear intent.

I like the idea of making the intent clearer like this, but if we don't rely on the UIKit lifecycle it will change the timing of the notice. Using viewWillDisappear ensures that the notice doesn't appear before the view is dismissed. Otherwise, the notice shows up while the view is still visible:

I prefer the timing that it has now, but I've updated the dismiss action in 7aa749f so it's more clearly connected to the notice. (This also resolves the Xcode warning you observed.) This way it still uses the UIKit lifecycle for the notice timing, but it also makes it clearer that we're both dismissing the view and handling the notice.

errorSelectingTimeRange feels like duplicated information when we already have notice set and error thrown. Can we trigger notice+dismiss in the catch clause?

That's reasonable. It feels a little odd to me to call UI code directly in the view model, so I've updated the catch clause in 228f144 to just set the notice (removing errorSelectingTimeRange). Then, the view handles the dismiss action with the provided notice when the notice is set. (I've moved that to a separate .onReceive modifier to handle both the initial sync and refresh actions.)